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Problem Introduction 


There are over 40 subsystems being 
developed for the future SLS and Orion 
Launch Systems at Kennedy Space Center. 
These subsystems are developed at the 
Kennedy Space Center Engineering 
Directorate. 


Solution 


The Engineering Directorate at Kennedy Space 
Center follows a comprehensive design process 
which requires several different product 
deliverables during each phase of each of the 
subsystems. 

This Presentation describes this process with 
examples of where the process has been applied. 


Responsible agents 


The responsible agents for success are: 

Project manager 
o Systems engineer 
o Receipt desk 

o Stakeholders such as chief engineer, operations 
engineer, materials and process engineer, 
reliability engineer, safety and mission assurance 
engineer, environmental engineer, human factors 
engineer, logistics engineer, information 
engineers, configuration/data management reps, 
and external disciplines experts. 


Responsible agents 


Systems Engineer shall: 

Coordinate system interfaces end-to-end. 

o Integrating the system design with other elements 
of the project. 

o Provide technical assistance, inputs, and 
necessary technical documents for the review. 

o Verify that interfaces are identified and 
understood at each design review. 

o Lead the design team in the review and disposition 
of submitted comments prior to the review. 

o Verifying entrance criteria for Informal Technical 
Reviews, including the content and readiness of 
technical review packages. 


Process Flow 
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Concept of Operations 



Systems Engineer shall: 

o Coordinate system interfaces end-to-end. 

o Integrating the system design with other elements of the 
project. 

o Provide technical assistance, inputs, and necessary technical 
documents for the review. 



Concept of Operations - GCS 
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Concept of Operations - Pad GCS 


Interface Diagram 





Concept of Operations - GCS 

Functional Architecture 


Liqutt'Gaseous Refract -► liqud Refrigerant 
P*3$e Charging Heat Exchange 



Liqu<J Refrigerant -► Air 

Heal Exchange 



Concept of Operations - GCS 

he primary operations for the Pad GCS are: 


Connection - This step identifies integration with 
the ground cooling facility at the Pad. 

• Close the isolation valves and hoses. 

• Connect the hoses. 

• Open the isolation valves. 

• Run the loops to condition the loop. 

• Etc... 

o Pre-Operations - This step identifies setup 
activities and necessary conditions for operations. 

• Fluid Flow and Reservoir(s) Level Check 

• Etc... 


Systems Requirements 


One of the key systems engineer products that are 
reviewed is the requirements related to the 
subsystem. 

o These requirements originate from the program as 
level 1 and 2 requirements. As an example of a 
high level requirement from the Space Shuttle 
would be: The Space Shuttle Shall use solid rocket 
motors. 


o Then these level 1 and 2 program requirements 
are further defined in the projects through the 
development of child level 3 and 4 requirements, 
and ultimately to level 5 requirements as they are 
defined by the systems design engineer. 


Systems Requirements 


Along with these program requirements the design 
engineer may decide it necessary to add additional 
requirements that may not be driven by level 1 or 
2 parent requirements. 

• An example of additional subsystem level 5 requirements 
is the Human Factors Assessment requirements. 

Once the requirements and the other products 
related to the system are generated, experts can 
review all of the requirements and provide Review 
Item Discrepancies (RIDS) and Action Items to the 
product owners so that corrections can be made. 
This is accomplished through the Technical 
Reviews. 


Systems Requirements - Pad GCS 


Pad GCS The Pad GCS shall receive Rationale: Pneumatically 

Compressed Aircompressed air supply to driven vacuum pumps are 
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support refrigerant 
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the Interface Table.... 


planned to be used to provide 
the capability to recover 
refrigerant. 


Pad Local 
Control 


The Pad GCS Subsystem 
shall provide local 
software control and 
monitoring to acquisition 
and control points 
specified in the Interface 
Table. 


The plan is for subsystems to 
implement application 
software to control subsystem 
hardware. 


Technical Reviews 


Technical Reviews are conducted for the purpose of 
informing all affected organizations of the progress 
of a system's development in preparation for key 
decision points in the formulation and 
implementation phases of the project life cycle. 

Technical Reviews are accomplished in progressive 
steps as the system is developed to allow those 
affected organizations to anticipate problems that 
could be avoided before the hardware or software is 
procured or fabricated. The number of Technical 
Reviews required will depend on the significance and 
complexity of the system, or changes in 
requirements. 


Technical Reviews 


A technical review is an evaluation of the project, or 
element thereof, by a knowledgeable group for the 
purposes of: 

o Assessing the status of and progress toward 
accomplishing the planned activities. 

o Validating the technical tradeoffs explored and 
design solutions proposed. 

o Identifying technical weaknesses or marginal 
design and potential problems (risks) and 
recommending improvements and corrective 
actions. 


Technical Reviews 


Making judgments on the activities, readiness for 
the follow-on events, including additional future 
evaluation milestones to improve the likelihood of 
a successful outcome. 


o 


e. Making assessments and recommendations to 
the project team, Center, and Agency 
management. 


o f. Providing a historical record that can be 
referenced of decisions that were made during 
these formal reviews. 


o g. Assessing the technical risk status and current 
risk profile. 


Technical Reviews 


System Requirements Review (SRR) and 
Preliminary Design Review (PDR) are conducted 
during the formulation phase of a project. 


o 


The System Requirements Review (SRR), 
Preliminary Design Review (PDR), and Critical 
Design Review (CDR) are conducted during the 
design phase of a system 


o Test Readiness Review (TRR), and System 
Acceptance Review (SAR)/Design Certification 
Review (DCR) are conducted during the 
implementation phase of a project culminating in 
transition from the design and development 
community to the operational community. 


Technical Reviews 


ngineering Products are required for each design 
eview, 30%, 60% 90%. Examples of products are: 

o Concept of Operations 

o Requirements 

o Lessons Learned Plan/Report 

o Human Factors Assessment 






Purpose of the 30% Design Review 


he 30% Design Review demonstrates that the 
reliminary design meets all system requirements 
with acceptable risk and within the cost and 
schedule constraints and establishes the basis for 
proceeding with detailed design. It will show that 
the correct design options have been selected, 
interfaces have been identified, and verification 
methods have been described. 


Purpose of the 60% Design Review 


L. 

significant progress has been made in the design 
since the 30% review and that the design meets 
all system requirements with acceptable risk 
within the cost and schedule constraints and 
confirms readiness to proceed with detailed 
design. It will show that the design is sound, 
interfaces have been defined to a significant 
extent, and verification methods have been 
confirmed. 


Purpose of the 90% Design Review 


The 90% Design Review establishes the system 
design baseline. It is conducted just before 
committing the design to procurement. It allows 
all affected customers and organizations to 
review the design to ensure their requirements 

have been satisfied. 


30% Design Review Presentation 


During the 30% design review the below areas 
are required to be covered in the presentation: 


o Purpose 
o Review Process 
o Process Tailoring Matrix 
o Subsystem Description 
o Entrance Criteria 
o Comment Disposition 
o Comments Statistics 


o Technical Issues Resulting 
from Review 

o Summary of Risks 

o Acquisition Strategy 

o Schedule Milestones 

o Success Criteria 

o Recommendation 


Example - GCS Subsystem Description 


Ground Cooling Subsystem for the Pad is Ground 
upport Equipment (GSE) located in the Ground 
Cooling Facility at the ground level of the LC 39 Pad 
B. The GCS loads and circulates coolant through the 
Flight to Ground Heat Exchanger to reject heat from 
the crewed vehicle. The GCS nominally operates 
during all Orion powered up activities during ground 
processing. 



Example - GCS Subsystem Description 


Fluids Drawing 



Examples - GCS Subsystem Description 



Because the fluids system has been very robust and 
has been kept in excellent condition, there will most 
likely not be any major changes to that portion of 
the subsystem, but in order to interface with the 
new control systems being put in place at the KSC, 
the electrical portion of the GCS is going through 
the design reviews. 



Examples - GCS Subsystem 
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30% Design Review Presentation 


Entrance Criteria , Comments Statistics, 
Technical Issues, Summary of Risks, 
Acquisition Strategy, Schedule Milestones, 
Success Criteria, and Recommendations are 
all also presented at the review. 


Summary 

For many years Kennedy Space Center has 
performed design development using the systems 
engineering approach for the specialized processing 
of spacecraft for crewed vehicles, from Mercury, 
Gemini Apollo, International Space Station, to the 
recent Space Transportation System's for out of Low 
Earth Orbit, i.e. Moon, Mars, etc., developments 
stemming from the Constellation Program. 

Because of the expertise carried down from the past, 
and because of the merging of new technologies 
coupled with the improved processes Kennedy Space 
Center is gaged for outstanding successes in crewed 
spaceflight for the 21st Century. 
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